This invention relates to the field of decision services. In particular, the invention relates to efficient rule execution in decision services.
A decision service is an autonomous component serving decision requests and returning decision outputs based on decision logic. This is typically operated with business rules and a rule engine.
Decision services may be applied in the area of middleware and large enterprise software, including service oriented architectures, software-as-a-service architectures, web services, decision management and business process management. There is a need in the domain of decision services to increase their performance and scalability.
A ruleset in a decision service is a stand-alone executable container that can be used by a rule engine. It contains a set of rules and rule artifacts that will be executed by the rule engine. A ruleset organizes and stores the rules that are related to a given business decision.
Automation of decision processing based on large rulesets remains a challenge in terms of performance and scalability. The size of rulesets executed in decision services reaches tens of thousands of rules and is increasing up to millions in rising high volume personalization applications.
The authoring and governance of high volume of business rules results commonly in the deployment of a single monolithic ruleset to take a decision. Despite the fact that monolithic packaging is the most convenient way, this approach introduces several difficulties at runtime including the following:                A significant startup time: loading all the rules to handle all business cases to process only one is more expensive compared to the time needed for one case only;        A larger footprint: the monolithic multipurpose ruleset requires memory and CPU to run all the rules even if a subset of them may be eligible for a particular business case; and        A longer execution time: depending on optimization of the rule engine the execution performance may be deeply impacted by the ruleset size even if only a subset is used.        
The usual response to get execution scalability to serve multiple requests in parallel is to put in place a pool of engines running a ruleset on a unique machine or a cluster. A decision request is sent to the cluster that routes it to a node to be processed with the expected ruleset. This distribution strategy is efficient to get scalability to handle multiple requests but does not address the challenges raised by a high volume monolithic ruleset. When (re)starting a cluster member, and moreover when starting a full cluster in disaster recovery, the monolithic ruleset approach requires to fully load the decision resources even if requests to serve concern only a particular business case.
Cost to start-up a large monolithic ruleset remains high when a machine is restarted or when the ruleset is garbaged. In this case ruleset and engine caching/pooling strategies are inefficient. Due to this, a web site leveraging a rule based decision service may need a few minutes or tens of minutes depending on the implementation and the ruleset complexity to be up and running
Classical cluster strategy does not solve either the start-up time of a large monolithic ruleset. This approach increases the execution scalability but performances remain limited by the intrinsic performance of a large monolithic ruleset due to its rule and condition evaluation complexity.
There is also significant evaluation cost due to the fact that many rules with their conditions and tests are packaged in the same runtime container with a single lifecycle.
Therefore, there is a need in the art to address the aforementioned problems.